При работе устройств Bluetooth используются специфические протоколы для Bluetooth и общие, используемые в различных телекоммуникационных системах. Все они образуют стек протоколов.

Примером вертикального списка протоколов может служить список vCard/vCal > OBEX > RFCOMM > L2CAD > Baseband, который используется в протокольных задачах обмена информацией о деловых карточках. Этот протокольный стек содержит соглашение о внутреннем представлении объектов (vCard) и протокола передачи через эфир (остальная часть стека).

Различные приложения могут использовать различные протокольные стеки. Тем не менее, каждый их этих стеков использует передачу данных (data link) и физический слой, общий для Bluetooth. Смысл каждого из протоколов, специфических для Bluetooth, может быть объяснен отдельно. Все они были разработаны группой специальных интересов Bluetooth SIG. Протоколы RFCOMM и бинарный протокол управления телефонией TCS BIN также были разработаны этой группой, но они основаны, соответственно, на стандарте ETSI TS 07.10 и на рекомендации Q.931 Международного союза электросвязи.

Помимо этих протокольных слоев спецификация Bluetooth определяет также интерфейс контроллера головной машины (HCI — Host Controller Interface), который дает командный интерфейс к контроллеру базовой полосы (baseband controller), диспетчеру соединений (link manager), и доступ к аппаратным регистрам статуса и управления.

Три слоя — слой замены кабеля, слой контроля телефонии и слой воспринятых протоколов (adapted protocol layer) — совместно определяют совокупность протоколов, ориентированных на приложения, которые позволяют прикладным задачам исполняться над корневыми протоколами Bluetooth.

Спецификация Bluetooth является открытой и дополнительные протоколы (например, HTTP, FTP и т.д.) могут быть подключены поверх специфических транспортных протоколов Bluetooth или поверх протоколов, ориентированных на приложения.

Корневые протоколы Bluetooth требуются для большинства приборов, тогда как остальные протоколы используются только там, где они нужны.

Базовая полоса и уровень управления подключениями Link Control Layer обеспечивают физическую радиочастотную связь между устройствами Bluetooth, образующими пикосеть. Поскольку радиочастотная система Bluetooth является системой прыгающей частоты распределенного спектра, внутри которой пакеты передаются в определенные временные интервалы на определенных частотах, этот уровень использует процедуры опроса и пейджинга для синхронизации (согласования) прыгающей частоты передачи и таймеров различных приборов Bluetooth.

Этот уровень предоставляет два различных способа физического подключения с соответствующими пакетами базовой полосы — синхронным, (SCO) и асинхронным (ACL).

Протоколы могут передаваться в режиме мультиплексирования по одному и тому же радио-звену (RF link). ACL-пакеты используются только для передачи данных, тогда как SCO-пакет может содержать только аудионформацию, или же представлять собой смесь аудио и данных. Для каждого типа данных, включая сообщения об управлении подключениями и контроле, выделяются специальные каналы.

Модель работы с аудио в Bluetooth сравнительно проста и два устройства Bluetooth могут посылать аудио-данные друг другу и получать их, просто открыв аудио-звено (audio link).

Протокол диспетчера подключений (LMP — Link Manager Protocol) ответственен за установление подключений между устройствами Bluetooth. Сюда же относятся вопросы безопасности, такие как аутентификация и шифрования, связанные генерированием ключей шифрования и подключения, а также с обменом ключами и их проверкой. LMP имеет более высокий приоритет чем остальные протоколы (например L2CAP), поэтому если канал занят чем-либо другим, то при необходимости передать LMP сообщение он немедленно освобождается.

Кроме того, менеджер подключений контролирует режимы питания и исполнительные циклы приборов Bluetooth, а также состояние подключения того или иного прибора к пикосети.

Протокол управления логическим подключением и адаптацией (L2CAP — Logical Link Control and Adaptation Protocol) адаптирует протоколы верхнего уровня над базовой полосой.

Logical Link Control and Adaptation Layer Protocol ака L2CAP, является базовым протоколом передачи данных для Bluetooth. Baseband protocol позволяет устанавливать синхронные (Synchronous Connection-Oriented, ака SCO) и асинхронные (Asynchronous Connection-Less, ака ACL) соединения. L2CAP работает только с асинхронными соединениями. Многие протоколы и службы более высокого уровня используют L2CAP как транспортный протокол. В полном соответствии с идеологией Bluetooth L2CAP является простым протоколом, который предъявляет минимум требований к вычислительным мощностям и размеру оперативной памяти устройств, которые его используют. Основные особенности, заложенные в L2CAP таковы:

1. Protocol Multiplexing. L2CAP является транспортом для многих протоколов и служб, поэтому он обеспечивает возможность разобраться, к какому протоколу или службе относится переданный пакет, что обеспечивает доставку пакета именно тому, кто его ждёт.

2. Segmentation and Reassembly.Максимальной длиной пакета для L2CAP является 64 килобайта, для baseband protocol это число ещё меньше, всего 341 байт. Однако, иногда требуется передача больших пакетов, поэтому L2CAP обеспечивает разбивку большого пакета на несколько более мелких, и последующую сборку первоначального пакета.

3. Quality of Service. Благодаря L2CAP Bluetooth устройства могут отслеживать свободные ресурсы соединения и не позволять, чтобы ширина канала или временные задержки для отслеживаемой службы опускались ниже критических значений.

4. Groups. L2CAP поддерживает адресацию не одному клиенту, а сразу целой группе.

Одним из важнейших протоколов Bluetooth, который использует L2CAP в качестве транспортного протокола, является Service Discovery Protocol, ака SDP, уже упоминавшийся в статье.

Сейчас никто не сможет представить все возможные способы использования Bluetooth устройств, поэтому при разработке этого протокола пытались учесть как можно больше ситуаций, которые могут возникнуть. Сейчас действует версия 1.0 этого протокола, и основные особенности, которыми он располагает, в настоящее время таковы:

1. SDP должен позволять поиск служб по специальным атрибутам этих служб. Например, если имеется несколько принтеров, доступных через Bluetooth, то клиент должен иметь возможность найти именно тот принтер, который ему нужен.

2. SDP должен позволять клиенту искать службы по классу. Если немного переделать предыдущий пример, то если клиенту понадобится принтер, то должна быть возможность найти именно устройство печати, не зная про него ничего другого.

3. SDP должен позволять просматривать службы без необходимости знать специфические характеристики этих служб. Например, если устройство предоставляющее какую-либо услугу может управляться только специальным программным обеспечением по какому-либо очень редкому или закрытому протоколу, то для SPD это не будет проблемой, всё равно можно будет получить информацию о доступности и названии службы.

4. SDP должен предоставлять возможности для обнаружения новых служб, которые появились за время работы.

5. SDP должен предоставлять возможность узнавать, когда служба становится недоступной из за того, что клиент вышел за пределы связи, или по какой-либо другой причине.

6. SDP позволяет службам, классам служб и атрибутам служб быть однозначно идентифицированными.

7. SDP должен позволять одному устройству находить любую службу на любом другом устройстве без обращения к третьему устройству.

8. SDP должен подходить для использования устройствами с ограниченной функциональностью.

9. SDP должен позволять увеличивать количество доступной информации о службе. Это означает, что если служба требует подробного и объёмного описания своих возможностей, параметров, ограничений и т. п., то вся эта информация не будет вываливаться на всех, кто просто спросит о доступности службы, а будет предоставлена только тем, кто более пристально заинтересуется именно этой службой.

10. SDP должен поддерживать использование промежуточных кэширующих агентов для ускорения или повышения эффективности процесса поиска новых служб. Этот пункт не противоречит пункту 7, потому что использование третьего устройства возможно, но не обязательно.

11. SDP должен быть полностью независим от протоколов более высокого уровня, используемых Bluetooth соединением.

12. SDP должен работать когда в качестве его транспортного протокола используется L2CAP.

13. SDP должен позволять находить и использовать службы которые обеспечивают доступ к другим протоколам обнаружения служб. Это позволяет расширять возможности системы, и использовать службы и устройства которые не имеют Bluetooth интерфейса.

14. SDP должен поддерживать создание и определение новых служб без необходимости централизовано регистрироваться.

Кроме этого, есть ряд вещей, которые пока что не входят SDP, но очень возможно, что в следующих редакциях спецификации многие из них станут обязательными:

1. SDP 1.0 не предоставляет механизма доступа к службам, только информацию о службах.

2. SDP 1.0 не предоставляет возможности оценивать службы. То есть, с его помощью нельзя автоматически выбрать наиболее подходящую службу, если доступно сразу несколько служб, предоставляющих похожий сервис.

3. SDP 1.0 не позволяет договариваться о параметрах службы.

4. SDP 1.0 не позволяет узнать о загруженности службы, или устройства предоставляющего службу.

5. SDP 1.0 не даёт возможности клиенту управлять службой.

6. SDP 1.0 не позволяет уведомлять о том, что служба или информация о службе становится недоступной.

7. SDP 1.0 не позволяет уведомлять о том, что атрибуты службы изменились.

8. В настоящее время спецификация не описывает интерфейса, через который программы должны обращаться к SDP.

9. SDP 1.0 в настоящее время не обладает развитым механизмом управления списком служб

10. SDP 1.0 не позволяет накапливать и регистрировать службы.

Используя протокол Service Discovery Protocol, можно запросить информацию о самом приборе, о его услугах и о характеристиках этих услуг, а после этого может быть установлено соединение между двумя или несколькими приборами Bluetooth.

Ещё одним из протоколов которые используют L2CAP в качестве транспортного является, как видно из приведённой выше схемы, RFCOMM. Этот протокол эмулирует соединение PPP (point-to-point) по серийному порту (RS-232 или EIATIA-232-E, более известным как COM-порты).Он обеспечивает также транспортировку при выполнении услуг верхнего уровня, которые используют последовательную линию как транспортный механизм. Через него работает такие службы как, например,LAN Access. Эта служба может работать как эмуляция Direct cable Connection, когда надо обеспечить связь между всего двумя PC, так и использоваться для полноценного входа в уже существующую локальную сеть. Во втором случае используется устройство под названием LAN Access point, через которое компьютер с Bluetooth оказывается подключен к LAN так, как он мог бы подключиться через dial-up соединение.

Двоичный протокол управления телефонией (TCS Binary или TCS BIN) — протокол, ориентированный на биты. Он определяет контроль сигнализации вызова для установления речевого вызова или вызова данных между устройствами Bluetooth. Вдобавок он определяет процедуры управления мобильностью при манипулировании с группами TCS-приборов Bluetooth.

Группа специальных интересов Bluetooth SIG определила набор АТ-команд, с помощью которых можно управлять мобильным телефоном или модемом в режиме моделей мультииспользования.

Команды, используемые при FAX-услугах, специфицируются реализацией. Это могут быть FAX-услуги класса 1.0 и класса 2.0.

Voice или Bluetooth audio одна из служб Bluetooth которая использует синхронное соединение. Как уже говорилось, одновременно может передаваться до 3 аудиоканалов. Характеристики звуковых потоков могут различаться, и во многом определяются используемым приложением. Максимально звуковой поток может передаваться с точностью в 16 бит при sampling rate 48 кГц. К сожалению, характеристики Bluetooth не позволяют передавать видеоинформацию с нормальным качеством.

Обычно для передачи аудиоинформации используется специальный протокол, который работает непосредственно с baseband protocol, но для этого с успехом может применяться и L2CAP. L2CAP предоставляет меньше возможностей для передачи аудио информации, чем Bluetooth voice, но этот метод незаменим когда необходимо, к примеру, обмениваться аудио-информацией между Bluetooth и не Bluetooth сетями. Кроме этого, данный метод хорош когда требуется дополнительная защита данных. Bluetooth может обеспечить ещё более надёжную защиту, при большем удобстве и меньшей стоимости.

В технологии Bluetooth протокол PPP (point-to point protocol) должен работать «поверх» RFCOMM. Соединения PPP служат средством, позволяющим перемещать IP-пакеты с уровня РРР на уровень локальных сетей.

В настоящее время семейство протоколов TCP/IP используется наиболее широко во всем мире. Стеки TCP/IP установлены на самых разных устройствах. Встраивание этих стандартов в приборы Bluetooth позволяет осуществлять связь с любым другим устройством, подключенным к Internet. Такой прибор Bluetooth, будь то сотовый головной комплект «наушники-микрофон» или точка доступа к данным, используется затем как «мостик» к Internet.

TCP/IP/PPP используется во всех сценариях спецификации Bluetooth 1.0 как мостик к Internet, а также как транспортный механизм для протокола WAP.

Протокол IrOBEX (Infrared Objet Exchange Protocol) или, короче, OBEX, является сеансовым протоколом, разработанным ассоциацией IrDA для простого, поэтапного обмена объектами. OBEX, обеспечивающий функциональность, сходную с НТТР, использует модель клиента-сервера не зависит ни от транспортного механизма, ни от транспортного API-интерфейса. Наряду с самим протоколом — «грамматикой» для ОВЕХ-переговоров между приборами — ОВЕХ дает также модель для представления объектов и операций. Вдобавок ОВЕХ определяет оглавление папок, которое используется для просмотра содержимого папок, находящихся на удаленных устройствах.

На первом этапе протокол RFCOMM используется как единственный транспортный слой для ОВЕХ; более поздние реализации скорее всего будут поддерживать в качестве транспорта также и TCP/IP.

Форматы vCard (обмен электронными деловыми карточками) и vCalendar (обмен электронными календарными данными) являются открытыми спецификациями, которые были разработаны консорциумом Versit и контролируются сегодня консорциумом Internet Mail. Сами по себе vCard и vCalendar не определяют никакого транспортного механизма. Они определяют только форматы данных, которые должны транспортироваться.

Два других формата содержимого, которые передаются протоколом OBEX, — это форматы vMessage («сообщение») и vNote («заметка»). Они также являются открытыми стандартами и используются для обмена сообщениями и замечаниями. Они определены в спецификации Инфракрасных мобильных коммуникаций (IrMC — Infrared Mobile Communications). Там же определен формат журнальных файлов, который необходим для синхронизации данных между отдельными приборами.

Протокол беспроводных приложений (WAP — Wireless Application Protocol), разработанный Форумом WAP, должен работать в самых разнообразных беспроводных сетях.

Цель состоит в том, чтобы распространить содержимое сети Internet и ее телефонные услуги на цифровые сотовые телефоны и на другие беспроводные терминалы

Идея, стоящая за разработкой WAP, — повторно использовать приложения верхнего уровня, разработанные для среды WAE (WAP Application Environment).

К таким приложениям относятся браузеры WML и WTA, способные взаимодействовать с приложениями на ПК. Построение шлюзов для приложений, обеспечивающих связь между WAP-серверами и приложениями на ПК позволяет реализовать различные виды «скрытой» функциональности, такие как дистанционное управление, передача данных с ПК на телефонную гарнитуру и т.д.

Использование «Синего Зуба» облегчается разработкой моделей использования. Каждая модель использования сопровождается ее «профилем». Профиль определяет протоколы и их специальные свойства (feature), поддерживающие данную модель использования.

Группа специального интереса Bluetooth SIG определила значительный набор моделей использования совместно с их профилями.

Кроме того, имеются четыре профиля «общего назначения», которые широко используются в более специальных профилях.

К ним относятся:

• GAP — типовой профиль доступа;
• SPP — профиль последовательного порта;
• SDAP — профиль обнаружения прикладных услуг;
• GOEP — профиль общего назначения для обмена объектами.

Протоколы Bluetooth предназначены для быстрой разработки прикладных задач, использующих эту технологию. Нижние уровни протокольного стека Bluetooth спроектированы так, чтобы обеспечить гибкую основу для дальнейшей разработки протоколов. Другие протоколы, такие как RFCOMM, полученные адаптацией существующих протоколов, которые лишь слегка модифицируются для этих целей. Протоколы верхнего уровня используются без модификации. Благодаря такому подходу существующие прикладные задачи могут использоваться для работы с технологией Bluetooth, а интероперабельность достигается с минимальными усилиями.